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D. REMARKS 

Status of the Claims 

Claims 1-20 are currently present in the Application, and 
claims 1,9, and L3 are independent claims* Claims 4 and 16 have 
been amended to correct minor, inadvertent typographical errors. 

Examiner Interview 

Applicant's representative attempted to contact the 
Examiner in order to set up an interview, however, the Examiner 
is out of the Office until early March. Applicant's 
representative will attempt to contact the Examiner after she 
returns to the Office. 

Drawings 

The Office Action did not indicate whether the formal 
drawings filed by the Applicant are accepted by the Examiner. 
Applicant respectfully requests that the Examiner indicate 
whether the drawings filed on March 26, 2001 are accepted by the 
Examiner in the next communication. 

Amendments to the Specification 

The specification has been amended to add the serial 
numbers of co-pending applications. 

Claim Rejections - Alleged Anticipation Un der 35 U.S.C. § 102 

Claims 1-3, 9-10, and 13-15 stand rejected under 35 U.S.C. 
§ 102(e) as being anticipated by Sehr, U.S. Patent No. 6,085,97 6 
(hereinafter Sehr). Applicant respectfully traverses the 
rejections under 35 U.S.C. § 102(e). 

Applicant teaches a method, system, and computer program 
product for printing tickets that include security features. 
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These security features can be used, for example, to stop the 
activities of ticket thieves or hackers. The printed ticket can 
be used to quickly check the identity of the ticket holder 
against both the security features found on the ticket as well 
as security features stored at the point-of-service location 
that is collecting the tickets. When the ticket holder wishes 
to transfer a ticket that includes security features to another 
person, the ticket holder requests that the ticket merchant 
unbind the security features from the ticket identifier of the 
ticket in question* If the ticket holder is authorized to 
transfer the ticket, the merchant unbinds the security features 
from the ticket. To enhance security, the new ticket holder 
(i.e. the ticket holder to whom the original ticket holder 
transfers the ticket) may request that the ticket merchant 
rebind the ticket to security features corresponding to the new 
ticket holder. 

In contrast tc Applicant's claimed invention, Sehr teaches 
a system and method for storing travel related information using 
"smart card" technology, where the travel related data is stored 
on the smart card (see Abstract). Sehr teaches ways of storing 
data, including biometric data, onto smart cards in a manner 
such that the stored data can be verified and validated at 
various point-of -service locations (see Abstract). However, 
Sehr does not teach or suggest unbinding security features from 
electronic tickets, as taught and claimed by Applicant in 
independent claims 1, 9, and 13. 

To anticipate a claim, the reference must teach every 
element of the claim (Manual of Patent Examining Procedure, § 
2131). Each of Applicant's independent claims includes at least 
the following limitations: 
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• receiving an unbind request from a requestor, the 
unbind request including the ticket identifier 
corresponding to the electronic ticket; 

• determining whether the unbind request is authorized by 
the customer; and 

• unbinding the security features from the ticket 
identifier in response to determining that the unbind 
request is authorized* 

The Examiner cites several sections of Sehr, i.e. col. 5, 
lines 23-24, col. 13, lines 64-67, and col. 14, lines 1-14, and 
asserts that these sections teach an electronic ticketing tool 
for unbinding a ticket identifier from security features. 
However, the cited sections of Sehr merely indicate that data 
stored on Sehr' s passenger cards may be edited (col. 14, lines 
1-3). As discussed by Sehr, a wide variety of data may be 
stored on a passenger card, and may be manipulated as needed in 
order to use the card (col. 13, lines 39-63). However, there is 
absolutely no discussion in Sehr of ^unbinding the security 
features from the ticket identifier" as taught and claimed by 
Applicant* As an initial matter, the passenger cards disclosed 
by Sehr are not analogous to the electronic tickets as taught 
and claimed by Applicant. Even assuming, for the sake of 
argument, that Sehr' s passenger cards were somehow analogous to 
electronic tickets, Sehr still does not teach or suggest 
unbinding security features from ticket identifiers • This would 
be comparable to allowing a user to transfer his or her 
passenger card to another person, and a close reading of Sehr 
reveals that Sehr never contemplated the transfer of its 
passenger cards. 
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The Examiner also cites Sehr at col, 15, lines 38-67 , col. 
17, lines 36-42, col. 29, lines 57-67, and col. 30, lines 1-7 
and 20-4 3, as teaching elements of Applicant's independent 
claims. Applicant respectfully disagrees with the Examiner* 
None of the cited sections of Sehr teach or suggest "receiving 
an unbind request from a requestor, the unbind request including 
the ticket identifier corresponding to the electronic ticket," 
"determining whether the unbind request is authorized by the 
customer," and "unbinding the security features from the ticket 
identifier in response to determining that the unbind request is 
authorized," as taught and claimed by Applicant in independent 
claims 1, 9, and 13. 

For example, the Examiner cites Sehr at col- 15, lines 38- 
67 ♦ This portion of Sehr merely discusses allowing a passenger 
to pre-select and/or change a seat assignment. Although Sehr 
allows a passenger to change a seat assignment, a seat 
assignment is hardly analogous to "security features," and 
changing a seat assignment is simply not the same as "unbinding 

. security features from the ticket identifier, " as taught 
and claimed by Applicant. The Examiner also cites Sehr at col. 
17, lines 36-42. This portion of Sehr discusses software 
applets to ^authenticate the card and identify the cardholder" 
(col. 17, lines 38-39). However, this portion of Sehr does not 
teach or suggest "determining whether the unbind request is 
authorized by the customer" as taught and claimed by Applicant . 
Rather, this portion of Sehr discusses authenticating the 
passenger card itself and identifying the cardholder. It does 
not have anything to do with receiving or authorizing an unbind 
request. 

The Examiner further cites Sehr at col. 29, lines 57-67 and 
col. 30, lines 1-7. This portion of Sehr discusses 
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authenticating a passenger card "via any read/write device 
installed at a point-of-application or via the control module 
coupled to a passenger station-like apparatus" (col. 29, lines 
57-60 )♦ This portion of Sehr goes on to note that NX selected 
card data can be validated as well" (col. 30, line 1). Access 
codes, security keys, and digital signatures are mentioned as 
possible ways to validate data (col. 30, lines 2-5). However, 
nothing in this section of Sehr -teaches or suggests that any 
security features can be unbound from the passenger card, as 
taught and claimed by Applicant in independent claims 1, 9, and 
13. 

The Examiner also cites Sehr at col. 30, lines 20-43. This 
portion of Sehr discusses determining if an application request 
should be approved by verifying a card-based code (col. 30 , 
lines 27-31). If a verification process is successful, the 
application is implemented (col. 30, lines 31-33). However, 
there is no teaching or suggesting of unbinding any security 
features, such as the card-based code, from the passenger card. 
This portion of Sehr simply does not teach or suggest "unbinding 
the security features from the ticket identifier in response to 
determining that the unbind request is authorized" as taught and 
claimed by Applicant. 

There is nothing in Sehr that teaches or suggests allowing 
a user to unbind security features from an electronic ticket, as 
taught and claimed by Applicant. Sehr' s passenger cards appear 
to rely on associating one passenger per card, and there is no 
indication that Sehr ever contemplated allowing a passenger to 
be able to transfer his or her card to another person. For the 
reasons set forth above > Applicant respectfully submits that 
independent claims 1, 9, and 13, and the claims which depend 
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from them, are not anticipated by Sehr, and respectfully 
requests that they be allowed. 

Claim Rejections - Alleged Obviousness Under 35 IT.S.C. § 103 

Claims 4-8, 11-12, and 16-20 stand rejected under 35 LKS.C. 
§ 103(a) as being unpatentable over Sehr in view of Goldstein et 
al., U.S. Patent No* 6,216,227 (hereinafter Goldstein). 
Applicant respectfully traverses the rejections under 35 U.S«C. 
S 103. 

As discussed above, Sehr does not teach or suggest 
unbinding security features from an electronic ticket, as taught 
and claimed by Applicant, and therefore claims 1-20 are 
allowable for at least the reasons discussed above. 
Notwithstanding the patentability of claims 1-20, Applicant also 
respectfully submits that Goldstein does not overcome the 
deficiencies of Sehr. 

Goldstein purportedly teaches storing electronic tickets 
for events at multiple venues on a single electronic device, 
such as a smart card or hand-held computer (col. 2, lines 1-6). 
'"Each venue for which a ticket has been stored on a smart card . 
. . has an associated applet stored on the smart card. A shared 
ticketing applet is also stored" (col, 3, lines 17-20). Venue 
applets are associated with individual venues, while a shared 
ticketing applet is used by all venue applets to provide 
^functions commonly available to, and used on behalf of, each of 
the venue applets" (col. 3, lines 42-47). 

Applicant' s dependent claims 4 and 16 include at least the 
f ol lowi ng elements : 

• determining whether the electronic ticket can be 
transferred; 
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• unbinding the security features from the ticket 
identifier in response to determining that the ticket 
can be transferred; and 

• returning an error message to the requestor in 
response to determining that the ticket cannot be 
transferred. 

The Examiner cites Goldstein at col. 6, lines 22-63 as 
teaching the elements of Applicant's claims 4 and 6. However, 
the cited section of Goldstein discusses loading applets, such 
as the venue applets and the shared applet discussed above, onto 
a smart card. If the shared applet can not be loaded, an error 
message is returned* Loading applets onto a smart card is not 
the same as unbinding security features from a ticket so that it 
can be transferred. Goldstein does not even address the general 
problem of transferring tickets, and, in particular, Goldstein 
does not teach or suggest "unbinding the security features from 
the ticket identifier in response to determining that the ticket 
can be transferred" as taught and claimed by Applicant. 
Applicant is at a loss to understand where in Goldstein the 
Examiner finds any teaching or suggestion of "unbinding the 
security features from the ticket." Applicant can find no 
teaching or suggestion of this element in the cited portion of 
Goldstein, or anywhere in Goldstein for that matter. 

Applicant's dependent claims 5, 11, and 17 include at least 
the following elements: 

• receiving a binding request from a second requestor, 
the binding request including a second ticket 
identifier and one or more security features 
corresponding to the second requestor; 
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• determining whether the second ticket identifier is 
currently bound to stored security features; and 

• binding the second ticket identifier to the second 
requestor' s security features in response to 
determining that the second ticket identifier is not 
currently bound to stored security features. 

The Examiner cites Goldstein at col. 4, lines 12-67, col. 
5, lines 1-37, and col. 8, lines 21-32 as teaching these 
elements. The portions of Goldstein cited in columns 4 and 5 
discuss a smart card "populated with the shared ticketing 
applet, multiple venue applets, and multiple tickets'' (col. 4, 
lines 12-14). This section of Goldstein discusses how the 
shared applet and the venue applets work, and in particular, 
addresses how venue signatures validate venue applets to the 
shared applet (col. 5, lines 1-7). The portion of Goldstein 
cited in column 8 further discusses loading a ticket onto a 
smart card, once the venue applet has been loaded. The venue 
applet validates a downloaded ticket by using a venue key (col. 
8, lines 21-32). Goldstein's process of using a shared applet 
and multiple venue applets to download and authenticate multiple 
tickets is interesting, but it hardly teaches or suggests 
"receiving a binding request from a second requestor, the 
binding request . . . including security features corresponding 
to the second requestor" as taught and claimed by Applicant . 
Goldstein also does not teach or suggest "determining whether 
the second ticket identifier is currently bound to stored 
security features, 7 ' and "binding the second ticket identifier to 
the second requestor's security features' 7 as taught and claimed 
by Applicant. Goldstein is not discussing a first and second 
ticket holder at all, and certainly is not discussing anything 
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having to do with binding and unbinding security features for 
first and second ticket requestors. Rather, Goldstein is 
discussing how to download multiple tickets for multiple venues 
onto a single smart card. 

Dependent claims 6 and 18 specifically claim a "ticket 
layout" and dependent claims 7 and 19 specifically claim 
"receiving a printed ticket from the second requestor, the 
printed ticket formatted according to the ticket layout . - . " 
Goldstein never mentions printing any of the tickets that are 
stored on the smart card, and actually teaches away from using 
any kind of paper or printed ticket. In the Background section 
of Goldstein, the disadvantages of printed tickets are discussed 
(col. 1, lines 28-40), and the entire point of Goldstein is to 
overcome the disadvantages of printed tickets by using a smart 
card, instead of printed tickets. 

Dependent claims 8, 12, and 20 claim "verifying a requestor 

. " The portion of Goldstein cited by the Examiner, i.e. 
col. 7, 1-25, has to do with authenticating downloaded applets, 
not with authenticating or verifying a requestor. 

None of the prior art r either alone or in combination, 
teaches or suggests Applicant's invention as claimed. 
Therefore, Applicant respectfully requests that claims 1-20 be 
allowed. 

Conclusion 

As a result of the foregoing, it is asserted by Applicant 
that the remaining claims in the Application are in condition 
for allowance, and Applicant respectfully requests an early 
allowance of such claims. 

Applicant respectfully request that the Examiner contact 
the Applicant's attorney listed below if the Examiner believes 
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that such a discussion would be helpful in resolving any 
remaining questions or issues related to this Application. 

Respectfully submitted, 

by J iMm$. q/ m<mwu fyO 

Leslie A. Van Leeuwen, Reg.. Wo. 42,196 
Joseph T. Van Leeuwen, Reg. Wo. 44,3 83 
Van Leeuwen & Van Leeuwen 
Attorneys for Applicant 
Telephone: (512) 301-6738 
Facsimile: (512) 301-6742 



Atty Ret No. IBM-1019 



Docket No. AUS920010280US1 Page 19 of 19 

Dutta - 09/817,844 



PAGE 22/22 ' RCVD AT 2/16/2005 12:34:44 PM [Eastern Standard Time] • SVR:USPTO-EFXRF-1/5 * DNIS: 8729306 * CSID: 51 2301 0742* DURATION (mm-ss): 07-44 



